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SHORT MESSAGING SERVICE CENTER MOBILE-ORIGINATED TO 
HTTP INTERNET COMMUNICATIONS 

BACKGROUND OF THE INVENTION 
5 1. Field of the Invention 

This invention relates generally to communications networks. 
More particularly, it relates to the communication between a mobile (i.e., 
wireless) device and an application server via a short message service 
center (SMSC) and the Internet. 

10 

2. Background of Related Art 

Wireless communication services are in increasing demand 
in response to a society which is becoming increasingly mobile. 
Traditionally, wireless communication services include voice cellular 

15 phone and paging services in which a user can make a telephone call or 
send/receive a page including a numeric message indicating a telephone 
number over a wireless network. More recently, paging services have 
been expanded to offer alphanumeric paging, which allows a short text 
based message to be sent to and displayed at a handheld pager. 

20 However, voice cellular telephone and the paging services 

each require an intended subscriber to be on-line or active to receive a 
telephone call or transmitted paging message. In other words, these 
services do not typically offer the capability of storing the messages for a 
temporarily unavailable subscriber. 

25 In the early 1990s, as a result of the growing popularity of 

digital wireless technology, a standard for digital wireless networks was 
introduced in Europe. That standard, now known as the global standard 
for mobiles (GSM), included a service called short messaging service 
(SMS). An SMS allows transmission of short messages, typically up to 

30 160 characters, to and from communication devices, e.g., cellular 
telephone handsets, telephones or computers with appropriate modems. 
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In North America, the SMS is currently implemented on digital 
wireless/mobile networks, such as a PCS network based on the GSM 
standard, code division multiple access (CDMA) and/or time division 
multiple access (TDMA) methods. Short message services are gaining in 
5 popularity, particularly in the United States. 

Short message services are advantageous over text based 
paging services because of the capability of bi-directional communication. 
Such bi-directional communication allows, for example, notification to the 
originating device of the success or failure of the short message delivery. 

10 Each SMS network typically includes a short message 

service center (SMSC) which acts as a store-and-forward mechanism 
providing guaranteed delivery of short messages to a subscriber, even if 
the subscriber is inactive when the message was transmitted, by 
delivering the short messages once the subscriber becomes active. 

15 Delivery of all short messages is guaranteed regardless of whether or not 
the intended subscriber is "on-line" because the transmitted short 
message is stored within the SMS network and delivered to the intended 
subscriber from their assigned SMSC when the subscriber becomes 
available. 

20 A variety of services have been introduced using SMS 

networks including, for example, integrated electronic mail and fax, 
integrated paging, interactive banking, and information services such as 
stock quotes and airline schedule delivery. 

In operation, an SMSC receives a short message from any 

25 source intended to be delivered to a particular subscriber. When the 
intended subscriber is not available because, for example, it is turned off 
or is outside of the service area of the SMS network, the attempt to deliver 
the short message at that time will fail. In this case, the short message 
will be retained in the SMS network for a later delivery attempt. 

30 Thereafter, when the subscriber finally becomes available, e.g., is turned 
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on or has moved into the service area of the SMS network, the relevant 
portions of the network (e.g., the mobile servicing center (MSC) and the 
home location register (HLR)) notify the SMSC to initiate delivery of the 
stored (i.e., previously failed) short messages. 
5 Fig. 6 shows an exemplary structure of a SMS network 500. 

Although the following example is described using terms and protocols 
mainly as defined by the North American standard IS-41, it will be 
apparent to one skilled in the art that the example is applicable to any 
networks that offer store-and-forward type short message service. 

10 ^the SMS network 500 typically included one short message 

service center (SMSC) 501. The SMSC 501 typically includes a storage 
subsystem to store short messages that b^d failed to be delivered. The 
SMSC 501 typically further includes/various interfaces (not shown) to 
receive short messages originating from various sources and protocols, 

15 such as a Voice Mail System (VMS) 508, paging networks using, e.g., 
Telocator Numeric Pagipg Protocol (TNPP) 509, devices using the Short 
Message Peer-to-Pe^r (SMPP) protocol 510 via TCP/IP, e-mail systems 
using the Simpte^ail Transport Protocol (SMTP) 511, and/or devices 
using the Tpfocator Alphanumeric Protocol (TAP) 512. Some of the 

20 various sources of the short messages may be gateways to other 
netwoj^s. 

The SMSC 501 may further include a gateway/interworking 
block (not shown) that enables the SMSC 501 to communicate with the 
rest of the SMS network 500, such as a Home Location Register (HLR) 

25 503 or a Mobile Switching Center (MSC) 505, using the Signaling System 
No. 7 (SS7) 502. The methods and mechanism of communication in the 
SMS network 500 are defined by the mobile application part (MAP) layer, 
which uses the services of the SS7 transaction capabilities application 
part (TCAP) as the signaling infrastructure of the SMS network 500. The 

30 protocol for the signaling is referred to as the IS-41 protocol under the 
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American standard as published by the Telecommunication Industry 
Association (TIA) or as the GSM MAP under the European standard 
published by European Telecommunication Standards Institute (ETSI). 

The Home Location Register (HLR) 503 includes a database 
5 that permanently stores and manages subscriptions and service profiles 
of users having a subscription to the SMS network 500. Although only 
one HLR 503 is shown, the SMS network 500 may include two or more 
HLRs. The SMS network 500 also typically includes several visitor 
location registers (VLR) 504. A VLR 504 is a database temporarily 
10 holding information about visiting subscribers who move into its service 
area. Thus, a VLR 504 contains information regarding routing information 

Q for all subscribers within its service area, and informs the relevant HLR 

m 503 of the availability and routing information regarding its subscribers. 

rg The mobile switching center (MSC) 505 obtains subscriber information 

^ 1 5 from the VLR 504 to service visiting subscribers. 

□ The mobile switching center (MSC) 505 performs switching 
o and call control functions, and receives short messages from the SMSC 
^ 501 for delivery to the appropriate mobile subscriber 507 (shown, e.g., as 
SjJ a cellular phone handset). It is to be understood that, although only one 

□ 20 MSC 505 is shown, the wireless network 500 may include two or more 

MSCs. « 

lUtji $~ ^he base station subsystem (BSS) &06 handles the wireless 

communications, e.g., RF transmission and reception of voice and data 
traffic, to and from the mobile subscriber 507. The BSS 506 is typically 

25 composed mainly of two parts: the base transceiver station (BTS, not 
shown) which houses the radio transceivers that define a cell and handles 
the radio-link protocols with the mobile subscriber 507, and the base 
station controller (BSC, also not/ shown) which manages the radio 
resources, and handles radio cbrannel set up, frequency hopping, and 

30 handoffs (or handovers as is Sometimes referred as). The BSC is the 
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interface between the MSC 505 and the su^criber 507. The subscriber 
507, also sometimes referred to as 2/ nobile station (MS), typically 
consists of mobile equipment (e.g.yB cellular phone handset) preferably 
uniquely identifiable by an identifying number, e.g., mobile identification 
5 number (MIN), InternationaKmobile subscriber identification (IMSI) and/or 
electronic serial number (ESN), for the subscriber 507. The mobile 
equipment may inpfude a storage area, e.g., a flash memory, a ROM, a 
RAM or the like to hold the unique identifying number within the mobile 
equipments/In GSM networks, a smart card, typically referred to as a 
10 subscriber identity module (SIM) is utilized to store a unique identifying 
numt^er. 

Fig. 7 shows an exemplary flow of a short message through 
a conventional SMS network. Although Fig. 7 shows only an example of 
short message delivery to a mobile subscriber, it is to be understood that 
15 a mobile subscriber or any other sources may originate a short message. 
The flow of a mobile subscriber originated short message would involve 
similar processes as the following mobile subscriber terminated short 
message example, and would be apparent to one of ordinary skill in the 
art. 

20 The SMSC 601 receives a short message intended for a 

subscriber 604 from a source of short message 605 which may be any 
one or more of the aforementioned sources of short messages, e.g., 508- 
512 of Fig. 6. Upon receiving a short message, the SMSC 601 sends a 
request for routing information, i.e., an SMS request (SMSREQ), to the 

25 HLR 602. The HLR 602 maintains information regarding the availability of 
the intended subscriber 604 and the appropriate MSC 603 that services 
the intended subscriber, and sends the information as routing information 
608 back to the SMSC 601. The SMSC 601 forwards the short message 
to the appropriate MSC 603 using the routing information 608 received 

30 from the HLR 602, for example, in accordance with the short message 
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delivery point-to-point (SMDPP) mechanism of IS-41 standard. The MSC 
603 queries the VLR (not shown) for subscriber information. The VLR 
may perform a paging and authentication process, and sends the 
subscriber information to the MSC 603. The MSC 603, using the 
5 information received from the VLR, delivers the short message to the 
intended subscriber 604, and sends a delivery report 612 to the SMSC 
601. The SMSC 601 may send the result of the delivery, i.e., the status 
report 613, to the source of the short message 605 if requested. 

When the attempted delivery of the short message has 

10 failed because, for instance, the intended user was out of the service 
area, or had his or her communication device turned off, the MSC 603 
informs the HLR 602 of the failure. The HLR 602 then turns on an SMS 
notification indicator flag for the subscriber, and the SMSC 601 retains the 
failed message for a later delivery attempt. 

15 Fig. 8 shows a pending short message delivery process in a 

conventional short message service network after the mobile subscriber 
becomes available for delivery of the retained messages. In particular, in 
Fig. 8, when the subscriber 704 turns his or her handset on or comes 
within the service area, the subscriber's handset sends a registration 

20 signal 709 to the MSC 703. The registration signal 709 may or may not 
include authentication process. 

Upon receiving the registration signal 709, the MSC 703 
informs the HLR 702 (or the VLR 711) of the availability of the subscriber 
704 by sending a subscriber available signal 708. Because the SMS 

25 notification flag for the subscriber is on, the HLR 702 or the VLR 703 
sends an SMS notification (SMSNOT) message 705 in case of networks 
implementing IS-41 standard, or an equivalent notification alerting the fact 
that the subscriber has become available in networks implemented in 
accordance with other standards, to the SMSC 701 assigned to service 

30 that particular intended subscriber 704. 
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The SMSC 701 then sends a delivery request 706 to the 
MSC 703 via, for example, the SMDPP protocol in the IS-41 standard. 
The MSC 703 finally delivers the short message 710 to the subscriber 
704, and sends a message delivered message 707 back to the SMSC 
5 701 to confirm and finalize the delivery of the short message. The SMSC 
701 may further send a delivery report to the source of the short message 
if it was requested. 

The Wireless Application Protocol (WAP) attempts to 
standardize a mechanism for two-way communications. However, WAP 
10 requires that a special browser be loaded on the handset, and requires 
the user to enter into a dedicated 'browser mode' in order to interact with 
P 2-way services. 

There is a need for a standardized solution allowing short 
message communications between wireless devices and application 
15 servers on the Internet without the need for a specialized browser, while 
making use of existing communication standards utilized by standard 
SMSCs, e.g., SMPP. 

: _ £ SUMMARY OF THE INVENTION 

'p^ 20 V|n accordance with thp^fJrinciples of the present invention, a 

gateway comprises a first copprfnunication path to accept a short message 
from a short messa^^ervice center. A translation module inserts the 
short messagerinto an HTTP protocol message. A second 
communication path transmits the HTTP protocol message to at least one 

L ^ A method of communicatinp4)etween a wireless device and 

an application program on an InternetTrotocol server in accordance with 
another aspect of the present invention comprises sending a short 
message from the wireless dej/ce to the Internet Protocol server. The 
30 short message is routed using a wireless protocol message. The short 



01 



7 



message is conveyed id^the Internet Protocol server using an HTTP 
protocol POST message. 

A mobile to HTTP gateway application in accordance with 
yet another aspect of the present invention comprises an SMPP relayer, a 
5 message director to process messages from the SMPP relayer, a poster 
collector to obtain at least one target poster, and a poster. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Features and advantages of the present invention will 
10 become apparent to those skilled in the art from the following description 
with reference to the drawings, in which: 

Fig. 1 illustrates an exemplary system adapted to push 
mobile originated (MO) messages to an IP (web) sever, in accordance 
with the principles of the present invention. 
15 Fig. 2 depicts a mobile-to-HTTP gateway (MHG) as a 'black 

box 1 which is easily installed into existing systems to enable bi-directional 
communication between a mobile device and one or more IP servers 
within the parameters of standard protocol communications (e.g., SMPP 
and HTTP) between system elements, in accordance with the principles of 
20 the present invention. 

Fig. 3 shows a message flow between the system elements 
shown in Fig. 1. 

Fig. 4 shows software elements of an exemplary MO-HTTP 
Gateway (MHG) 100, in accordance with the principles of the present 
25 invention. 

Fig. 5 shows various classes in an exemplary embodiment 
of a MHG 100, in accordance with the principles of the present invention. 

Fig. 6 shows relevant portions of a conventional short 
message service network. 
30 Fig. 7 shows a process of short message flow within a 
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conventional short message service network. 

Fig. 8 shows a pending message delivery process in a 
conventional short message service network. 

5 DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 

The present invention provides a mobile-to-HTTP protocol 
gateway (MHG, or "MO Gateway") which translates between standard 
wireless protocol commands (e.g., SMPP from an SMSC), and an 
application server on the Internet (i.e., a "Web Server"). 

10 An MHG in accordance with the principles of the present 

invention allows any standard 2-way SMS capable handset to interact with 
specialized web applications. Using an MHG, it is no longer necessary for 
a user to launch a phone browser in order to access the services. 
Moreover, an MHG provides a simpler model than WAP for developing 2- 

15 way applications. 

The disclosed embodiment of an MO-HTTP gateway uses 
the SMPP protocol. However, the principles of the present invention 
relate equally to other 2-way messaging protocols, e.g., ReFlex for 2-way 
pagers. 

20 The MO-HTTP gateway provides a mechanism for 

developers to produce 2-way wireless applications using familiar Web- 
based tools and methodologies. The MO-HTTP gateway hides the details 
of communicating with the wireless network by interacting with 
applications using familiar HTTP posting. By adopting SMS and SMPP 

25 for its reference implementation, the MO-HTTP gateway avoids problems 
common to the WAP environment. 

Utilizing an MHG in accordance with the principles of the 
present invention, a developer may create mobile applications using 
standard Web development tools, e.g., Java Servlets. 

30 Fig. 1 illustrates an exemplary system adapted to push 
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mobile originated (MO) messages to an IP (web) sever using 
standardized equipment and message protocols together with an MHG 
100, in accordance with the principles of the present invention. 

In particular, as shown in Fig. 1, a mobile (i.e., wireless) 
5 device 120 communicates with an appropriate wireless network 122 using 
any appropriate wireless standard protocol. In turn, the wireless network 
122 communicates with a short message service center 124 using 
standard IS-41 communication protocol messages. 

Appendix A attached hereto is a document entitled "SHORT 
10 MESSAGE PEER TO PEER (SMPP) INTERFACE SPECIFICATION" 
describing relevant features of mobile originated communications using 
Short Message Peer-to-Peer Protocol (referred to herein as SMPP). 
n The SMSC 124 communicates with a wireless internet 

■!% gateway 126 via SMPP protocol commands in substantial conformance 

F 1 5 with the SMPP interface specification attached hereto in Appendix A. 

suitable wireless Internet gateway 126 is described in co- 
owned U.S. Appl. No. 60 / A , filed on , 2000, entitled 

"Wireless Internet Gateway/1 by Richard Smith, the entirety of which is 
expressly incorporated herein by reference. 
20 The wireless Internet Gateway 126 communicates with a 

MHG 100 using Java Remote Method Invocation (RMI) technology to 
provide server-to-server capability. 

The mobile to HTTP Gateway (MHG) 100 translates 
standard format RMI protocol commands from the wireless Internet 
25 gateway 126 into HTTP protocol commands, and directs the same to an 
appropriate Internet protocol (IP) server (i.e., web application server) 152, 
154, and/or 156 in communication with the Internet 150. 

Fig. 2 depicts the MHG 100 as a 'black box' which is easily 
installed into existing systems to enable bi-directional communication 
30 between a mobile device 120 and one or more IP servers 152-156 within 
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the parameters of standard protocol communications (e.g., SMPP and 

HTTP) between system elements, in accordance with the principles of the 

present invention. 

In particular, as shown in Fig. 2, the mobile to HTTP 

5 gateway (MHG) 100 preferably is bi-directional in that it generates HTTP 

protocol POST commands to an application program on a relevant IP 

server 152-156 based on mobile-originated messages, and translates 

responses to the same from HTTP protocol back into standard format 

SMPP messages for forwarding back to the relevant mobile device 120. 

10 accordance with the principles of the present invention, an 

HTTP protocol POST command is us^a by the MHG 100 to forward a 

r% request from the mobile device 120/o the relevant web IP server(s) 152- 

156. The HTTP protocol POST oommand is well known and documented 

Oj in, e.g., RFC2068 and later \ETV RFC's on the subject. This document is 

!5 1 5 publicly available, e.g., at http://ietf.org/rfc.html . 
St -i A 1 
\f$b ?^/f ln P articular > as is known wjJMh the HTTP protocol, an HTTP 

l _ protocol POST command is used to/request that a particular destination 

01 web IP server 152-156 accept th^entity enclosed in the request (i.e., the 
^ mobile device 120) as a new/subordinate of the resource identified by the 

2 20 Request-URI in the Reqt^t-Line. 

O 

The HTTP protocol POST command is designed to allow a 
uniform method for various tasks, e.g., to allow annotation of existing 
resources, to allow posting of a message to a bulletin board, newsgroup, 
mailing list, or similar group of articles, to provide a block of data, such as 

25 the result of submitting a form, to a data-handling process, and/or to 
extend a database through an append operation. The actual function 
performed by the HTTP protocol POST method is determined by the 
particular web IP server 152-156, and is usually dependent on the 
Request-URI. The posted entity (i.e., the wireless device 120) is 

30 subordinate to that URI in the same way that a file is subordinate to a 



11 



US 



directory containing it, a news article is subordinate to a newsgroup to 
which it is posted, or a record is subordinate to a database. 

The action performed by the HTTP protocol POST command 
might not result in a resource that can be identified by a URL In this case, 
5 either 200 (OK) or 204 (No Content) is the appropriate response status, 
depending on whether or not the response includes an entity that 
describes the result. If a resource has been created on the origin server, 
the response should be 201 (Created) and contain an entity which 
describes the status of the request and refers to the new resource, and a 
10 location header. 

Responses to the HTTP protocol POST are not cachable, 
unless the response includes appropriate Cache-Control or Expires 
header fields. However, the 303 (See Other) response can be used to 
direct the user agent to retrieve a cachable resource. 
15 ^With respect to the MKG 100, the submitted HTTP protocol 

POST command includes mpbne_num, resp_trackjd and body fields. 
Also embedded within the HTTP protocol POST command is a CGI 
name/value pair providing information about the particular request from 
the mobile device^O. 
20 A response back to the mobile device 120 originates from 

the relevant web IP server 152-154 synchronously in response to the 
received HTTP protocol POST command. 

Particular features of the standard SMPP utilized by various 
aspects of the present invention include the following: 
25 • Use of a registered_delivery flag. 

• Use of an "$R" trigger in the body of every MO message indicating 
a source-unique tracking number for SMPP v3.3, version 3.4 
provides an explicit field for a tracking number and therefore the 
trigger is not required. 
30 • Use of user responses contained within the stat component of a 
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standard delivery receipt. 
• Use of message types identified by the esm_class field. 

Fig. 3 shows an exemplary message flow between the 
5 system elements shown in Fig. 1. 

In particular, the following steps 1 to 12 are depicted 
between system elements in Fig. 3 as an example of message routing 
between a mobile device 120 and a relevant web IP server 152-154. 

10 Step 1 

The mobile device 120 sends a short message to a pre- 
defined address (e.g., 'info', or 4636). If the body of the short message is 
empty, or if the body contains a special string such as 'menu\ then 
ultimately a menu would be sent by the HTTP Application on the relevant 

15 web IP server 152-156 to the mobile device 120. 

Other bodies may be used to, e.g., identify global 
commands, or provide context-sensitive information from the mobile 
device 120 to the HTTP application on the web IP server 152-156. 
Requirements for body content depend on the particular HTTP application 

20 as it exists on the particular web I P server 1 52-1 56. 

Step 2 

The SMSC 124 routes the short message to an ESME (e.g., 
the wireless Internet gateway 126) for delivery using a standard SMPP 
25 protocol DELIVER_SM message. As disclosed, the MHG 100 utilizes the 
following fields of the DELIVER_SM command: service_Jype, 
source_addr, destination_addr, registered_delivery_flag, esm_class, and 
shortjriessage. 

In particular, the MHG 100 utilizes the service_type 
30 parameter to indicate the SMS application service associated with the 
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message. For instance, the servicejype field may be populated with the 
value 'page 1 . 

The source_addr is the address of the SME (e.g., mobile 
device 120) that originated the short message. As disclosed, the 
5 source_addr is the Mobile Identification Number (MIN) of the mobile 
device 120 making the request. 

The destination_addr is the address of the destination SME. 
As disclosed, the destination_addr may be assumed to be '4636' as 
indicated in Step 1 above. This address is used to route the request to 
10 the appropriate HTTP URL. 

The registered_delivery_flag indicates if an SME 
Acknowledgement is necessary. As disclosed, the 

registered_delivery_flag is set to a default value of 0, which indicates that 
no delivery receipt is requested. 
15 The esm_class indicates the message type and Enhanced 

network services. 

The shortjnessage field contains up to 254 octets of short 
message user data. 

Thus, key fields of the DELIVER_SM command may be 
20 populated by the MHG 100 as follows: 
service_type: page 
source_addr: mobile's MIN 

destination_addr: 4636 
registered jJelivery_flag: 0 
25 esm_class 0 

shortjnessage: $R[new ref id]$M[message] 

The $R in the shortjnessage is optional, and is applicable 
for use with SMPP v3.3. The $R may be used when correlating 
responses from the mobile device 120 to Reply-request messages from 
30 the application program on the relevant web IP server 152-156. For 
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consistency, the $R is preferably always present in short messages from 
the mobile device 120. 

Step 3 

5 When the wireless Internet gateway 126 receives the SMPP 

message from the SMSC 124, it creates a DELIVER_SM object. The 
DELIVER_SM object is forwarded by the wireless Internet gateway 126 to 
any relevant remote applications that are registered to receive messages 
on a specified ports/link ID, e.g., the MHG 100 if the MHG 100 is 
10 registered with the wireless Internet gateway 126 to receive SMPP 
messages. The transmission is accomplished through an RMI callback 
mechanism. 

Step 4 

15 The MO-HTTP Gateway (MHG) 100 receives the 

DELIVER_SM message object from the wireless Internet gateway 126, 
and formulates an HTTP protocol POST command message to a web 
server on the Internet 150 to convey the message content. The MHG 100 
can direct the HTTP protocol POST command messages to one or to 

20 multiple URLs. 

The particular web server to reference is determined by the 
included destination address, assuming that the SMPP destination 
address field contains the targeted number, e.g.,, '4636'. The HTTP 
protocol POST command message may be routed based on the SMPP 

25 port utilized. 

As disclosed, exemplary name/values that may be utilized in 
the HTTP protocol POST command message sent to the web server are 
the mobilejium, resp_trackjd, and body. 

The mobilejium may be the mobile identification number 
30 (min) identifying the originating mobile number of the relevant mobile 
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device 120. 

The resp_track_id may be the reference ID (ref id) for user 
acknowledgements used to track questions and related answers. 

The body may be the payload content from the mobile 
5 device 120 included in the message body field. 

As embodied, by default, only SMPP messages with 
esm_class values of '0' and '16* are forwarded by the wireless Internet 
gateway 126 to the web IP server 152-156. That is, only new mobile 
originated requests and/or menu responses are forwarded. 
10 If, for instance, the SMPP message type is '16\ then the 

resp_track_id variable may contain the reference ID. On the other hand, if 
the message type is '0\ then the reference ID is not passed to the 
relevant web IP server(s) 152-156. 

Utilization of the SMPP message type and inclusion/non- 
15 inclusion of the reference ID reduces network traffic and resource 
requirements, and simplifies development on the web side. 

Step 5 

The relevant web server in the Internet 150 receives the 
20 HTTP protocol POST command information, which may be handled by the 
actual CGI/Servlet routine specified by the URL in Step 4. 

The handling servlet may create sessions for each mobile 
device such that the current state of the mobile device may be preserved, 
allowing meaningful content to be transmitted. Example wireless web 
25 applications may include menu-based services, games, and information 
services. 

After the servlet of the web server in the Internet 150 
receives the HTTP protocol POST command, the servlet synchronously 
returns data through the HTTP stream back to the MHG 100. The text 
30 returned by the servlet may be delivered to the mobile device 120 as a 
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standard SMS message. 

The returned data may be contained within an <SMS> and 
</SMS> tag-set. The <SMS> and </SMS> tags are special tags used by 
the MHG 100 to denote SMSC Type data. As the number and/or variety 
5 of applications increase, additional tags may be implemented. 

As disclosed, there are several fields embedded within the 
<SMS> and </SMS> tags: mobile_num, resp_track_id, and body. 

The mobile_num field includes a mobile identification 
number of the mobile device 120 that a relevant short message is 
10 destined for. 

The resp_track_id field includes a unique identification 
number generated by the servlet. The MHG 100 returns this id to the 
servlet for responses. 

The body field includes the text to send to the desired 
15 mobile device 120. If the body field is blank, then nothing will be sent to 
the mobile device 120. 

If the servlet requires a single-button user response (e.g., for 
a menu), then the "<RESP_TRACK_ID value='x'>" tag can be included 
prior to the </SMS> tag. This tells the system that a menu is required and 
20 that the specified unique tracking number should be used. 

When the user of the mobile device 120 responds to this 
message, this same tracking id may be returned in the resp_track_id cgi 
variable. 

For ease of description of some of the following steps, an 
25 example using the scenario described above is introduced wherein the 
servlet returns the following: 

<SMS> Do you like cookies (Y/N)? 

<RESP_TRACKJD value="1234"> </SMS> 

30 
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Step 6 

After having posted its data to the web server in the Internet 
150, the MHG 100 receives a response from the same connection, as 
described in Step 5. A standard SUBMIT_SM MT message is generated 
5 from the text received within the <SMS> tag set. 

In particular, the SUBMIT_SM message is issued by the 
ESME (e.g., the wireless Internet gateway 126) to submit a short 
message to the SMSC 124 for transmission to a specified mobile device 
120. In creating a SUBMIT_SM message destined for the SMSC 124, the 
10 conventional SMPP Protocol specification is followed, with the exception 
of the following mapping implemented between the SUBMIT_SM 
message and data received in the <SMS> and </SMS>. 

A registered_delivery_flag in the SUBMIT_SM message 
informs the SMS that the ESME (wireless Internet gateway) 126 requires 
15 a notification when the message has been delivered. If the 
RESP_TRACK_ID is provided (i.e., contains a value), then the 
registered_delivery_flag field is set to '8' for the MHG 100 indicating 'SME 
Manual/User Ack requested', and a special tag of R$[track id] is included 
in the message body. Preferably, this same tracking id will be returned in 
20 the response message from the mobile device 120. 

A shortjnessage in the SUBMIT_SM message is the 
payload containing up to 160 bytes of data that should be transmitted to 
the mobile device 120. An empty body indicates that no message is to be 
sent to the mobile. If the RESP_TRACK_ID value is set, then a special 
25 tag of "$R M concatenated with the value from the RESP_TRACK_ID and 
the tag "$M" must be prepended to the short message. 

The other fields of the SUBMIT_SM message are used as 
conventionally known and described in the SMPP Protocol. 
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Step 7 

The SMSC 124 receives the SUBMIT_SM message and 
delivers a short message, with manual ack request, to the mobile device 
120. 

5 

Step 8 

The mobile device 120 responds to the "Do you like 
cookies?" question, e.g., by pressing '9' for Yes. 



10 Step 9 

The SMSC 124 receives the response from the mobile 
device 120 and formulates a DELIVER_SM message. The formulated 
DELIVER_SM message is forwarded to the wireless Internet gateway 
126. 

15 Key parameters in the DELIVER_SM message may be 

populated as follows: 

• service_type: page 

• source_addr: [mobile's MIN] 

• destination_addr: 4636 
20 • registered_delivery_flag: 0 

• esm_class: 16 

• shortjnessage: R1234$[Response Value] 



The response code is shown directly after the $M value. 

25 

Step 10 

The wireless Internet gateway 126 receives the 
DELIVER_SM message from the SMSC 124, converts the DELIVER_SM 
message into an object, and forwards the DELIVER_SM message to any 
30 listeners (e.g., the MHG 100). In the disclosed example, the MHG 100 
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may be listening to the wireless Internet gateway 126 on a specified port, 
and therefore receive the DELIVER_SM message from the specified port. 

Step 1 1 

5 The MHG 100 receives the DELIVER_SM object, and 

determines if the esm_class is '16'. If so, the short message is translated 
by the MHG 100 and forwarded to its web listeners. 

A URL is associated with either the SMPP link ports or the 
destination address through a configuration file of the MHG 100. The 
10 MHG 100 therefore formulates an HTTP protocol POST command 
message to the appropriate URL(s). 

As disclosed, the HTTP protocol POST command message 
may contain the following name/value pairs: 
mobile_num=[mobile num] 
1 5 resp_track_id=1 23 

body=9 

To ease the burden of the web developer, the MHG 100 
may include the response code only for messages where esm_class- 16\ 
Thus, if the esm_class is not '16', the response code need not be 
20 included. Regardless of how the MSG 100 receives it, it need pass only 
the response code in the body field. 

Step 12 

The servlet associated with the specified URL receives the 
25 HTTP protocol POST command message from the MHG 100. 

The servlet may retrieve a session object for the particular 
value of the mobilejium, and determines that it had just asked the mobile 
device 120 about a cookie preference. 

The servlet may confirm that the query's tracking ID 
30 correlates to the resp_trackjd value. Thus, the servlet knows that the 
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response at hand is in response to that question. Since the body contains 
the content '9' (or 'Y' or other suitable response), the servlet may rightfully 
conclude that the user of the mobile device 120 (who input the '9' 
response) likes cookies. 
5 A conversation or communication between the mobile device 

120 and an application on one or more particular web IP servers 152-156 
may continue on as described in steps 1 to 12 indefinitely. 

Fig. 4 shows software elements of an exemplary MO-HTTP 
Gateway (MHG) 100, in accordance with the principles of the present 
10 invention. 

In particular, as shown in Fig. 4, the software elements of 
the MHG 100 include an SMPPRelayer 402, a MessageDirector 404, a 
PosterCollection 406, a Poster 408, and a Servlet 410. 

In accordance with the principles of the present invention, 
15 one or more SMPPRelayers 402 will register as listeners to specified link 
IDs of the wireless Internet gateway 126. 

In message 421 shown in Fig. 4, SMPP messages are sent 
by the wireless Internet gateway 126 to the SMPPRelayer 402 of the 
MHG 100 as they are received. 
20 In message 422, the SMPPRelayer 402 forwards each 

message to a MessageDirector 404. 

In message 423, the MessageDirector 404 retrieves a 
Poster 408 from the PosterCollection 406, and then in message 424 tells 
the Poster 408 to process the SMPP Message. 
25 In message 425, the Poster 408 converts the SMPP 

Message into an HTTP protocol POST command request 425 to a specific 
universal resource locator (URL), and receives return results back in 
message 426. 

In message 427, the Poster 408 returns the results back to 
30 the SMPPRelayer 402, so that it will be sent to the mobile device 120, as 
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depicted in message 428. 

Fig. 5 shows various classes in an exemplary embodiment 
of a MHG 100, in accordance with the principles of the present invention. 

In particular, as shown in Fig. 5, the MHG 100 includes a 
5 MOHGateway class 502, an SMPPRelayer class 402, a MessageDirector 
class 404, a PosterCollection class 406, and a Poster class 408. 

The MOHGateway class 502 defines "main()", and upon 
execution will create the SMPPRelayer class 402, the MessageDirector 
class 404, and the PosterCollection class 406, assigning references to 
1 0 one another as appropriate. 

The PosterCollection class 406 accesses a standard 
application resource class to determine the number of Posters 408 
required, as well as the desired configuration of each Poster 408. The 
PosterCollection class 406 creates the Posters 408 and provides 
15 references to the Posters 408 through a getPoster(SMPPMessage msg) 
method. 

The SMPPRelayer class 402, the MessageDirector class 
404, the PosterCollection class 406, and the Poster 408 each receive an 
'Logger object for recording information. 
20 While the invention has been described with reference to the 

exemplary embodiments thereof, those skilled in the art will be able to 
make various modifications to the described embodiments of the invention 
without departing from the true spirit and scope of the invention. 



22 



